home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text0495.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  2.2 KB  |  50 lines
  1.  
  2. >I once explained the current HTTP protocol to a local network guru and
  3. >he expressed concern that basing a protocol like this on TCP/IP is a
  4. >great waste of network resources, since you are using a
  5. >session-oriented protocol for what is essentially one remote procedure
  6. >call.
  7.  
  8. Do the WAIS folks know about this? I wonder what they'd say...
  9.  
  10. >  My question "then what would you recommend instead" provoked no
  11. >useful answer (what is needed is *reliable* datagrams, but these are
  12. >not implemented as an IP protocol; UDP requires too much coding for
  13. >time-out, retransmission and fragmentation).  Yet, he convinced me
  14. >that a light-weight protocol like this should minimize the number of
  15. >round-trips.
  16.  
  17. I agree.
  18.  
  19. >I have the feeling that the current trend of basing the new protocol
  20. >on NNTP violates that requirement.  I like the idea of borrowing
  21. >response and data formats from the FTP/SMTP/NNTP family of protocols,
  22. >with suitable extensions for 8-bit data paths.  However I don't like
  23. >it if compatibility with NNTP forces us to have an extra round trip
  24. >just so that the server can give its welcome message.
  25.  
  26. The idea was to use the existing usenet distributed database. But
  27. I guess we should just use plain old NNTP for that.
  28.  
  29. >Also, I don't like the fact that you must parse the RFC822/MIME header
  30. >to find out how many bytes are to be expected.  This seems to be
  31. >mixing two levels of protocols: MIME assumes that the end of the
  32. >message is already known, and the MIME headers then tell you what to
  33. >do with it.
  34.  
  35. I certainly didn't think it out very carefully, did I?
  36.  
  37. >As I see it, there are two possible ways of using MIME in HTTP+.  We
  38. >can either support MIME as the *only* data format (implementing any
  39. >extensions we need as new MIME content types or subtypes or additional
  40. >headers), or we we support MIME as one of the possible data formats.
  41.  
  42. A terminology note here: there is no one "MIME data format." There's
  43. the ubiquitous message/rfc822 format that you can stick anything
  44. inside using MIME techniques. But the basic unit of information
  45. in the MIME spec is an _entity_ -- just an arbitrary stream of bytes.
  46.  
  47. The question is, when you're sending an entity from one
  48. place to another, how do you know where the end is?
  49.  
  50.